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PREFACE 


The  text  of  this  Memorandum,  prepared  as  a  briefing 
for  the  Air  Force  Scientific  Advisory  Board  meeting  on 
"Military  Preparedness  in  Space,"  indicates  some  critical 
information  processing  problems  implied  by  Air  Force  space 
objectives  (and  also  by  other  Air  Force  objectives)  and 
recommends  steps  for  attacking  these  problems.  It  should 
be  of  interest  to  military  and  civilian  space  planners, 
and  to  military  information  system  plaaners  in  general. 

This  Memorandum  has  benefited  greatly  from  discussions 
with  J.  P.  Haverty  and  W.  H.  Mare  of  The  RAND  Corporation. 
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•  FOR  SOME  COMPUTING  CAPABILITIES,  USAF  MUST 

ACTIVELY  PUSH  R&D 

•  ON-BOARD  COMPUTERS:  BUY  50%  -  100%  EXCESS 

CAPACITY  TO  MINIMIZE  TOTAL  SYSTEM  COSTS 

•  STS:  SOFTWARE  DEVELOPMENT  IS  ALREADY  ON  THE 

CRITICAL  PATH 

•  SOFTWARE  CERTIFICATION  PROBLEM  UNDEREMPHASIZED; 

CONSIDER  DEDICATED  SOFTWARE  TEST  FACILITY 
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SUMMARY 


Most  military  space  operations  during  the  1970s  will 
not  strain  the  available  information-processing  capabili¬ 
ties.  But  there  are  some  operations — real-time  image  pro¬ 
cessing,  multi-sensor  data  analysis,  decision-oriented  dis¬ 
plays,  and  others — for  which  the  Air  Force  will  not  be  able 
to  reach  "on  the  shelf"  and  find  tools  capable  of  doing  the 
job.  The  USAF  will  have  to  settle  for  reduced  capabilities 
in  these  areas,  unless  space-mission  planners  more  thoroughly 
investigate  their  detailed  information  processing  require¬ 
ments  and  couple  them  more  effectively  to  the  USAF  R&D  pro¬ 
gram  in  information  processing. 

In  this  Memorandum  (the  text  of  a  briefing) ,  an  analysis 
of  observed  software  cost  trends  indicates  that  the  overall 
cost  of  an  on-board  computing  system  is  generally  minimized 
by  procuring  computer  hardware  with  at  least  50  percent  to 
100  percent  more  capacity  than  is  absolutely  necessary. 

The  proposed  Space  Transportation  System  (STS)  will 
strain  the  available  information  processing  capabilities. 
Historical  data  on  similar  software  projects  indicate  that 
six  or  seven  calendar  years  are  probably  required  to  design, 
develop,  and  check  out  the  software  for  a  project  of  the 
magnitude  and  complexity  of  STS.  To  make  sure  that  software 
does  not  slip  the  overall  schedule,  STS  planners  must  begin 
to  design  the  software  now.  Also,  the  USAF  should  push  R&D 
on  high-capability  flight  computers  for  STS. 

Preprogrammed  space  software  in  the  seventies  will 
allow  many  more  user  options.  Serious  consideration  is 
being  given  to  "programmer-astronauts"  and  real-time  soft¬ 
ware  modification  to  provide  non-preprogrammed  flexibility 
to  USAF  space-mission  operations.  But,  coupled  with  our 
inadequate  capabilities  to  check  out  and  certify  software, 
such  measures  could  have  disastrous  consequences  in 
escalating  strategic  crises  or  degrading  critical  defense 
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capabilities  because  of  undetected  errors  in  software 
options  or  modifications.  The  Air  Force  could  markedly 
improve  the  situation  by  following  its  hardware  develop¬ 
ment  philosophy  and  establishing  a  dedicated  facility 
for  software  testing  and  certification,  along  with 
operational  procedures  for  using  the  facility  during  a 
major  software  project  development. 
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HARDWARE  TRENDS  AND  OPERATIONAL  REQUIREMENTS 

This  Memorandum  opens  with  some  estimates  of  computer 
hardware  capabilities  that  the  Air  Force  can  reasonably  ex¬ 
pect  to  find  "on  the  shelf"  during  the  1970s.  Following 
these  estimates  are  discussions  of  1)  how  best  to  use  these 
capabilities  when  they  are  easily  sufficient  to  do  the  job, 
and  2)  some  space  operations  for  which  these  capabilities 
will  be  either  barely  sufficient  or  insufficient. 

Amdahl  [1]  has  indicated  the  probable  computing  capa¬ 
bilities  that  the  current  pace  of  technology  will  yield  to 
support  USAF  missions  in  the  seventies.  Due  primarily  to 
advances  in  large-scale  integrated  circuit  (LSI)  technology, 
the  speed  of  ground-based  computers  will  increase  from 
6,000,000  instructions/sec  to  60,000,000  instructions/sec 
between  1970  and  1980.  Also,  during  this  period  the  speed 
of  spaceborne  computers  will  increase  from  500,000  instruc¬ 
tions/sec  to  4,000,000  instructions/sec  due  to  advances 
both  in  LSI  and  circuit-packaging  technology. 

However,  Amdahl's  analysis  indicates  that— to  the  ex¬ 
tent  that  transfers  to  and  from  high-speed  memory  are  un¬ 
predictable  (due  to  real-time  interrupts,  accesses  to  lower- 
speed  memory,  etc.) — the  actual  performance  realized  by  the 
computer  as  a  system  will  drop  by  a  factor  of  four  (to 
15,000,000  operations/sec)  for  ground-based  computing  and 
by  a  factor  of  two  (to  2,000,000  operations/sec)  for  space- 
borne  computing. 

The  advances  in  speed  will  be  accompanied  by  advances 
in  hardware  reliability  and  reductions  in  cost,  size,  weight, 
and  power  requirements  for  spaceborne  computers.  For  ex¬ 
ample,  Amdahl  estimates  that  the  size  of  an  8,000,000-bit 
memory  will  decrease  from  75  cubic  feet  in  1970  to  2  cubic 
feet  in  1980. 
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MOST  MILITARY  SPACE  OPERATIONS 
WON'T  HAVE  TO  STRAIN 
THE  COMPUTER'S  CAPABILITY 


—  BUT  THIS  DOESN'T  GUARANTEE 


THAT  THEY  WON'T 
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MOST  JOBS  WILL  NOT  HAVE  TO  STRAIN  THE  HARDWARE 

The  computing  capacity  available  during  the  1970s 
will  easily  accommodate  most  of  the  information  processing 
requirements  of  USAF  space  missions.  Current  concepts  of 
navigation  satellite  systems,  life  support  and  environ¬ 
mental  monitoring  for  manned  missions,  and  basic  systems 
for  attitude  control  and  trajectory  guidance  and  control 
easily  fall  within  this  category.  (Some  operations  that 
will  strain  this  computing  capacity  are  discussed  below. ) 

However,  it  is  still  very  easy  to  produce  a  situation 
in  which  computing  capacity  is  strained.  One  way  is  to 
procure  a  small  computer  to  decrease  hardware  costs,  when 
larger  ones  are  available.  Another  is  to  absorb  any  excess 
computing  capacity  with  marginally  useful  tasks.  As  the 
next  figure  indicates,  both  of  these  practices  can  gravely 
inflate  software  costs. 


RELATIVE  PROGRAMMING  COST/ INSTRUCTION 


I _ I _ I _ I _ 

0  25  50  75 

%  UTILIZATION  OF  SPEED  AND  MEMORY  CAPACITY 


ON-BOARD  COMPUTING:  SOFTWARE  COSTS 
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ON- BOARD  COMPUTING;  SOFTWARE  COSTS 

This  figure  shows  how  dramatically  software  costs  in¬ 
crease  as  one  strains  the  capacity  of  the  computer's  central 
processing  unit.  It  is  based  on  the  experience  of  North 
American  Rockwell's  Autonetics  Division  in  developing  a 
large  body  of  software  for  aircraft,  missile,  and  space- 
borne  computers  [2]. 

Why  does  the  curve  look  like  this,  and  not  like  the 
"folklore"  curve?  Primarily  because  when  one  is  pushing 
the  computer's  capacity,  slight  gains  in  program  efficiency 
cam  only  be  bought  at  the  cost  of  logical  complexity.  Ma¬ 
chine  language  must  be  used  instead  of  higher-order  languages 
like  FORTRAN;  several  elements  of  data  must  be  packed  into 
a  single  machine  word;  and  many  tricky  programming  short¬ 
cuts  must  be  employed  with  scaling,  reusable  portions  of 
code,  and  the  like.  All  of  these  make  the  program  not  only 
harder  to  write  but  also  much  harder  to  check  out,  modify, 
and  coordinate  with  other  operations. 

Thus,  the  figure  indicates  that  current  folklore-based 
practices  of  specifying  computer  hardware  by  sizing  the 
data-processing  task  and  adding  perhaps  15  percent  for  con¬ 
tingencies  are  highly  inappropriate  if  software  constitutes 
an  appreciable  portion  of  the  cost  of  the  data-processing 
system,  or  if  the  sizing  is  subject  to  any  significant  error. 
The  next  two  figures  quantify  this  conclusion. 


50%  100%  50%  100% 

EXCESS  CPU  CAPACITY  PROCURED 


ON-BOARD  COMPUTING:  TOTAL  SYSTEM  COSTS 
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ON-BOARD  COMPUTING;  TOTAL  SYSTEM  COSTS 

Suppose  that  one  has  sized  a  data-processing  task  and 
determined  that  a  computer  of  one-unit  capacity  (with  re¬ 
spect  to  central  processing  unit  speed  and  size)  is  required. 
The  figures  on  the  opposite  page  show  how  the  total  data- 
processing  system  cost  varies  with  the  amount  of  excess 
Control  Processing  Unit  (CPU)  capacity  procured  for  various 

estimates  of  the  ratio  of  ideal  software- to-hardware  costs 
* 

for  the  system.  The  calculations  are  based  on  the  previous 
curve  of  programming  costs  and  two  models  of  hardware  cost: 
the  linear  model  assumes  that  cost  increases  linearly  with 
increases  in  CPU  capacity;  the  "Grosch's  Law"  model  assumes 
that  cost  increases  as  the  square  root  of  CPU  capacity. 
Sharpe's  data  [3]  indicates  that  most  applications  fall  some¬ 
where  between  these  models. 

It  should  be  remembered  that  the  curves  are  based  on 
imprecise  observations;  they  clearly  cannot  be  used  in  "cook¬ 
book"  fashion  by  system  designers.  But  even  their  general 
trends  make  the  following  points  quite  evident: 

1)  Overall  system  cost  is  generally  minimized  by 
procuring  computer  hardware  with  at  least  50  per¬ 
cent  to  100  percent  more  capacity  than  is  absolutely 
necessary. 

2)  The  more  the  ratio  of  software- to-hardware  cost 
increases  (as  it  will  markedly  during  the  seventies) , 
the  more  excess  computing  capacity  one  should  pro¬ 
cure  to  minimize  the  total  cost. 

3)  it  is  far  more  risky  to  err  by  procuring  a  computer 
that  is  too  small  than  one  that  is  too  large.  This 
is  especially  important  since  one's  initial  sizing 
of  the  data-processing  job  often  tends  to  under¬ 
estimate  its  magnitude. 


"Ideal  software"  costs  are  those  that  would  be  in¬ 
curred  without  any  considerations  of  straining  hardware 
capacity. 
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EXCESS  CPU  CAPACITY  PROCURED 


ON-BOARD  COMPUTING:  TOTAL  SYSTEM  COSTS 
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Of  course/  buying  extra  hardware  does  not  eliminate 
the  need  for  good  sot  ..ware  engineering  thereafter.  Careful 
configuration  control  must  be  maintained  to  realize  properly 
the  bensfits  of  having  extra  hardware  capability,  as  there 
are  always  strong  Parkinsonism  tendencies  to  absorb  excess 
capacity  with  marginally  useful  tasks. 
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•  IMAGE  PROCESSING 


•  STS  OPERATIONS 


•  SOFTWARE  CERTIFICATION 


SOME  CHALLENGING  REQUIREMENTS 
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SOME  CHALLENGING  REQUIREMENTS 

As  indicated  above,  the  computer  hardware  available 
during  the  seventies  will  allow  system  designers  the  "luxury" 
of  procuring  excess  computer  capacity  for  most  space  opera¬ 
tions.  However,  some  information-processing  requirements  of 
the  military  space  program  will  present  strong  challenges, 
including  the  correlation  and  analysis  of  data  from  large 
numbers  of  independent  sensors;  the  analysis  and  design  of 
decision-oriented  displays  for  military  commanders;  and  the 
general  problem  of  software  engineering,  or  management  of 
large  software  projects.  This  Memorandum,  however,  concen¬ 
trates  only  on  three  representative  topics:  1)  real-time 
image  processing,  2)  Space  Transportation  System  (STS) 
operations,  and  3)  software  certification. 
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REAL-TIME  IMAGE  PROCESSING 


The  requirements  for  real-time  image  processing  are 
implicit  in  many  military  operations  involving  such  ac¬ 
tivities  as  surveillance,  strategic  warning,  and  damage 
assessment.  The  figure  opposite  indicates  the  rough  number 
of  computer  operations  required  to  perform  a  typical  se¬ 
quence  of  tasks  on  a  rather  modest  image  containing  10  7 

O 

points  and  10  bits  of  information.  (For  comparison,  the 

7 

Mariner  6  and  7  photographs  had  about  10  bits  [4];  high- 

O 

resolution  Luner  Orbiter  pictures  have  5*10  bits;  high- 
quality  aerial  photographs  have  up  to  10^  bits  [5].)  The 
right-hand  number  in  the  operations/image  column  represents 
the  number  of  operations  required  if  no  effort  is  made  to 
conserve  operations;  the  left-hand  number  reflects  straight¬ 
forward  use  of  standard  programming  shortcuts  for  this  type 
of  task.  The  cross-correlation  entries  are  an  exception; 
there  the  range  reflects  whether  one  is  cross -correlating 
with  respect  to  a  single  point  or  with  respect  to  the 
entire  image  of  107  points. 

Thus,  even  using  currently  efficient  techniques,  one 

9 

cannot  perform  these  tasks  in  much  less  then  10  computer 
operations.  On  a  1980  computer,  realizing  15*10®  operations/ 
sec  (see  figure,  p.  x) ,  this  would  take  about  67  seconds: 
functional  for  some  activities,  but  not  very  satisfactory 
for  military  command  and  control.  Even  given  the  ideal 
computing  power  of  60*10®  instructions/sec,  the  task  would 
take  about  17  seconds,  and  this  on  a  relatively  low-quality 
image.  If  the  Air  Force  wishes  to  use  images  of  high  quali¬ 
ty,  or  perform  in  a  real-time  environment  more  extensive 
image-processing  tasks,  it  will  be  necessary  to  specifically 
define  the  image-processing  functions  required,  and  to 
actively  stimulate  research  and  development  efforts  towards 
performing  them  rapidly. 
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•  SERIAL  VS  PARALLEL  PROCESSING 


•  STORAGE  AND  RETRIEVAL 


•  GROUND  VS  SPACEBORNE 


•  AUTOMATED  PATTERN  RECOGNITION 


IMAGE  PROCESSING  CONSIDERATIONS 


li 


-15- 


IMAGE  PROCESSING  CONSIDERATIONS 

Parallel  processing  might  seem  an  ideal  solution  to 
the  real-time  image-processing  problem  because  many  of  the 
image-processing  tasks  involve  identical  local  operations 
among  neighboring  image  points.  Thus,  to  speed  things  up 
by  a  factor  of  N ,  one  simply  buys  N  parallel  processors. 
However,  recent  experience  on  the  Illiac  IV  experimental 
multiprocessor  indicates  that  even  jobs  highly  suited  for 
parallel  processing  still  carry  a  residual  serial  proces- 
ing  burden  of  about  5  percent.  This  experience,  if  typical, 
limits  the  gains  due  to  parallel  processing  to  a  factor  of 
20. 

Over  a  period  of  years,  an  image  archive  could  build  up 
to  a  storage  requirement  of  lO^-lO15  bits,  with  associated 
problems  of  defining  an  appropriate  indexing  and  cataloging 
scheme  for  images  and  a  related  query  language  for  users. 

Also,  the  space-time  tradeoff  question — either  storing 
multiple  copies  of  an  image  or  storing  a  single  copy  and 
reprocessing  it  on  demand — must  be  appropriately  resolved. 

One  promising  role  for  man  in  space  involves  the  in¬ 
terpretation  of  image  data  and  subsequent  reconfiguration 
of  sensors,  and  transmittal  of  summary  information  to  the 
ground.  This  would  greatly  reduce  the  daily  communications 
and  ground-processing  load;  however,  if  during  a  crisis  the 
ground  operators  want  to  be  able  to  do  their  own  processing, 
one  would  have  to  provide  the  communications  and  ground¬ 
processing  hardware  anyway.  Also,  another  alternative  for 
getting  man's  capabilities  into  space  deserves  further  con¬ 
sideration:  the  use  of  remote-controlled  teleoperators  [6,7]. 

The  Air  Force  should  not  expect  any  miracles  of  automated 
pattern  recognition  to  sweep  away  the  image-processing  problem. 
If  specific  mission-oriented  image-processing  functions  can 
be  defined  and  given  R6D  priority,  however,  the  USAF  can  expect 
the  results  to  yield  solid,  if  perhaps  unspectacular,  im¬ 
provements  in  processing  algorithms,  which  also  can  be  called 
useful  contributions  to  pattern-recognition  research. 
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•  ON-BOARD  LAUNCH  CHECKOUT  AND  CONTROL 

•  OF  STS  VEHICLE 

•  OF  VARIOUS  PAYLOADS 

•  WHOLE  NEW  LEVEL  OF  FLIGHT  CONTROL 

INFORMATION  PROCESSING:  STS  INNOVATIONS 
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INFORMATION  PROCESSING:  STS  INNOVATIONS 

As  currently  conceived,  the  Space  Transportation  System 
(STS) ,  or  space  shuttle,  involves  two  major  information-pro¬ 
cessing  innovations. 

The  first  is  the  use  of  an  on-board  computer  to  control 
the  countdown  and  launch  of  both  the  STS  vehicle  and  its 
interfaces  with  any  number  of  diverse  payloads  (and  perhaps 
the  payloads  themselves)  in  order  to  eliminate  expensive 
ground  checkout  equipment  and  operations.  Some  precedents 
exist  in  airplane  operations,  but  space  booster  operations 
will  have  many  significant  differences. 

The  second  major  innovation  involves  radical  advances 
in  flight  control:  the  on-board  computer  solving  heating 
and  structural  equations  in  real  time  as  inputs  to  a 
control  scheme  that  would  minimize  differences  between 
the  stress  history  of  the  vehicle  and  that  of  the  nominal 
flight  plan.  This  would  permit  a  considerably  lighter 
structural  design  and  a  correspondingly  lower  cost-per- 
pound  of  payload  in  orbit. 

Will  the  available  computer  hardware  support  these 
innovations?  At  this  time  it  is  very  difficult  to  say 
because  little  effort  has  gone  into  analyzing  the  infor¬ 
mation  processing  alternatives  available  to  STS;  e.g., 
centralized  versus  distributed  launch  checkout  control, 
software  versus  special-purpose  hardware  for  signal  pro¬ 
cessing,  or  analytic  versus  tabular  expression  of  flight- 
control  functions.  However,  a  general  feel  for  the  magni¬ 
tude  of  the  problem  can  be  gained  from  the  estimates  in 
the  next  figure. 


MEMORY  (WORDS) 


ON-BOARD  COMPUTING  REQUIREMENTS:  MID-1970'S 


STS :  HARDWARE  IMPLICATIONS 


This  figure  shows  some  estimates  by  Bellcomm  [8]  and 
Autonetics  [2]  of  on-board  computing  requirements  for 
missions  similar  to  those  of  STS.  The  Bellcomm  estimates 
for  checkout  requirements  depend  on  the  number  of  test 
points  monitored,  and  whether  or  not  the  computer  performs 
diagnosis  and  trend  analysis  over  and  above  monitoring. 

For  reference,  a  system  such  as  Apollo,  with  about  7000 
test  points,  would  require  a  computer  memory  of  250,000 
words  and  a  speed  of  400,000  operations/sec  to  perform 
checkout  monitoring,  diagnosis,  and  trend  analysis. 

Even  without  considering  the  added  demands  of  the  in¬ 
novations  in  flight  control,  the  total  load  on  the  STS  on¬ 
board  computer  will  be  heavier  than  any  present-day  flight 
computer  (e.g.,  the  IBM  4-PI)  can  support.  Even  the  com¬ 
puters  predicted  for  1975  by  Amdahl  would  be  hard-pressed 
to  handle  the  load.  Thus  STS  will  perforce  be  in  the 
position  of  straining  the  on-board  computer  hardware 
capacity,  a  situation  that  was  shown  in  the  figures  on 
pp.  4  and  6  to  have  serious  consequences  for  software 
development. 

A  useful  strategy  would  be  for  the  Air  Force  to 
push  the  development  of  high-capability  flight  computers. 

If  hardware  manufacturers  are  provided  incentives  beyond 
those  of  the  commercial  flight-computer  market  (most  of 
which  can  be  serviced  by  relatively  low-capability  com¬ 
puters)  ,  it  should  be  possible  to  improve  on  Amdahl's 
nominal  estimates  of  future  spaceborne  hardware  capability. 
Still,  the  complexity  and  indefiniteness  of  the  STS  infor¬ 
mation-processing  task  carries  serious  software  implications, 
as  seen  in  the  next  figure. 


PROGRAM  SIZE  (1000  WORDS) 


PROGRAM  DEVELOPMENT  TIME  VERSUS  SIZE  AND  DEGREE  OF 
SYSTEM  DEFINITION 


-21- 


STS :  SOFTWARE  IMPLICATIONS 


The  STS  software  will  be  quite  extensive,  the  programs 
requiring  considerably  more  than  30,000  words.  Also, 
neither  the  hardware  nor  the  software  techniques  for  the 
STS  on-board  processing  have  been  specified.  Considering 
these  attributes  in  the  context  of  other  on-board  program¬ 
ming  jobs  reported  in  an  SDC  study  [9] ,  one  can  easily 
expect  STS  on-board  program  development  to  require  five 
to  seven  years  of  calendar  time.  Thus,  if  one  wants  to 
fly  an  STS  by  1976  or  1977,  it  is  necessary  to  begin  de¬ 
signing  the  software  now. 

Specifically,  as  much  immediate  effort  is  needed  to 
resolve  such  questions  as  centralized  versus  distributed 
checkout  control,  and  software  versus  special-purpose  hard¬ 
ware  for  signal  processing,  as  is  needed  for  questions  of 
propellant  tanking,  thermal  protection,  and  the  like.  The 
Air  Force  must  make  sure  that  appropriate  software  contrac¬ 
tors  begin  now  to  analyze  STS  information-processing  prob¬ 
lems  in  detail. 

The  above  estimate,  based  on  analogy  and  extrapola¬ 
tion,  cannot  be  precise.  If  STS  planners  are  not  careful, 
however,  to  avoid  the  pitfalls  of  poor  software  engineering 
[10-12] ,  or  if  the  USAF  has  not  developed  and  retained 
skilled  software  management  personnel,  the  situation  could 
become  much  worse.  On  the  other  hand,  there  are  mitigating 
factors:  the  availability  and  increased  feasibility  of 
using  higher- level  programming  languages;  and  the  avail¬ 
ability  of  floating-point  arithmetic  in  on-board  computers 
(some  30  percent  of  the  Apollo  programming  effort  was 
devoted  to  fixed-point  scaling  ) . 

*A  percentage  of  this  magnitude,  coupled  with  the 
rising  costs  of  software  in  general,  indicates  the  necessity 
for  stronger  Air  Force  requirements  on  the  inclusion  of 
floating-point  hardware  in  on-board  computers. 


•  CRITICAL  PROBLEM  EVEN  NOW 


•  EXTRA  CRITICAL  IN  FUTURE 

DUE  TO  ADDED  FLEXIBILITY, 
ADDED  COMPLEXITY 


SOFTWARE  CERTIFICATION 
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SOFTWARE  CERTIFICATION 

Having  major  projects  like  STS  slip  their  schedules 
because  of  a  software  lag  could  be  a  serious  problem.  But 
there  are  software  problems  that  could  be  far  more  serious: 
escalating  a  strategic  crisis  situation  or  degrading  critical 
defense  capabilities  because  of  software  errors. 

Consider  the  following  scenario:  During  a  fairly  tense 
situation,  the  Soviet  Union  sends  up  a  large,  new  satellite. 
We  decide  to  use  a  previously  untried  combination  of  sensors 
on  an  inspection  satellite  to  take  a  look — an  option  avail¬ 
able  under  the  computer  program  that  controls  sensor  se¬ 
quencing.  But  under  a  certain  unlikely  combination  of  con¬ 
ditions,  which  was  not  checked  out,  this  software  option 
also  activates  a  high-intensity  electron  beam  used  for  war¬ 
head  detection.  This  happens  during  the  mission,  and  the 
electron  beam  kills  a  crew  of  six  in  the  satellite. 

In  this  or  similar  situations,  a  software  error  could 
quickly  precipitate  a  dangerous  strategic  confrontation. 

Or,  even  worse,  a  software  error  could  incapacitate  a  key 
component  of  our  defense  structure  at  a  critical  time. 

But  such  things  could  quite  easily  happen,  especially 
as  software  becomes  more  and  more  complex.  The  likelihood 
increases  even  further  if  we  opt  for  real-time  reprogram¬ 
ming,  or  programmer-astronauts,  without  a  great  deal  more 
attention  to  real-time  software  certification. 

Software  certification  is  not  easy.  Ideally,  it  means 
checking  all  possible  logical  paths  through  a  program;  there 
may  be  a  great  many  of  these.  For  example,  the  next  figure 
shows  a  rather  simple  program  flowchart.  Before  looking 
at  the  accompanying  text,  try  to  estimate  how  many  different 
possible  paths  through  the  flowchart  exist. 


LOOP  (<  12  TIMES) 


LOOP  (<  12  TIMES) 


HOW  MANY  DIFFERENT  PATHS  THROUGH  THIS  FLOWCHART? 
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DIFFICULTY  OF  FULL  SOFTWARE  CERTIFICATION 


Even  through  this  simple  flowchart ,  the  number  of  dif¬ 
ferent  paths  is  about  ten  to  the  twentieth.  If  one  had  a 
computer  that  could  check  out  one  path  per  nanosecond 
(10  sec) ,  and  had  started  to  check  out  the  program  at 
the  beginning  of  the  Christian  era  (1  A.D.),  the  job  would 
be  about  half  done  at  the  present  time. 

So,  how  does  one  certify  a  complex  computer  program 
that  has  incredibly  more  possible  paths  than  this  simple 
example?  Fortunately,  almost  all  of  the  probability  mass 
in  most  programs  goes  into  a  relatively  small  number  of 
paths  that  can  be  checked  out. 

But  the  unchecked  paths  still  have  some  probability 
of  occurring.  And,  even  in  the  most  thoroughly  checked 
systems,  software  errors  can  occur.  The  next  section  dis¬ 
cusses  this  problem  and  its  effect  on  the  Apollo  program. 


HOURS  OR  NUMBER 
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( COMPUTER  SYSTEM  CERTIFICATION) 
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APOLLO  SOFTWARE  CERTIFICATION 

As  the  figure  indicates,  the  Apollo  flights  provide 
outstanding  examples  of  thoroughness  in  testing  computer 
systems  [13].  Assuming  that  the  testing  system  can  certify 
one  path  through  the  program  per  millisecond,  200  hours  of 
testing  would  check  out  720,000,000  different  paths.  Yet 
there  are  many  more  paths,  and  sometimes  one  of  them  that 
produces  a  wrong  result  is  encountered  during  an  Apollo 
mission.  On  Apollo  8,  an  unforeseen  sequence  of  astronaut 
actions  destroyed  the  contents  of  a  word  in  the  computer's 
erasable  memory — fortunately,  not  a  critical  error  in  this 
case.  And  on  Apollo  11,  the  data  flow  from  the  rendezvous 
radar  was  not  diverted  during  the  critical  lunar  landing 
sequence,  causing  a  computer  overload  that  required  Astro¬ 
naut  Armstrong  to  divert  his  attention  from  the  process  of 
landing  the  spacecraft — fortunately,  again,  without  serious 
consequences . 

Computer  support  of  some  military  space  missions  will 
be  at  least  as  complex  as  that  of  Apollo,  with  two  additional 
factors  that  will  render  the  software  certification  problem 
even  more  difficult.  First,  the  military  systems  will  be 
far  less  organized  about  achieving  a  single  objective; 
second,  they  will  rarely  have  as  much  time  to  check  out 
program  modifications. 

One  might  feel  that  the  difficulties  in  checking  out 
the  Apollo  computer  system  would  disappear  if  there  were  only 
one  or  two  functional  changes  rather  than  several  hundred. 

To  some  extent,  this  is  true — but  consider  the  next  figure. 
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NUMBER  OF  STATEMENTS  MODIFIED 
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CERTIFICATION  AND  SMALL  SOFTWARE  MODIFICATIONS 

These  observations  on  modifying  computer  programs  indi¬ 
cate  that  small  modifications  have  a  better  chance  of  working 
successfully  than  do  large  ones.  However,  even  after  a  small 
modification,  the  chance  of  a  successful  first  run  is,  at 
best,  about  50  percent.  In  fact,  there  seems  to  be  a  sort 
of  complacency  factor  operating  that  makes  a  successful  first 
run  less  probable  on  modifications  involving  a  single  state¬ 
ment  than  on  those  involving  approximately  five  statements — 
at  least  for  this  sample. 

At  any  rate,  it  appears  that  the  problem  of  certifying 
software  modifications  does  not  disappear  even  for  small 
changes.  And,  since  there  are  generally  many  paths  a  pro¬ 
gram  may  take  to  and  from  the  region  of  software  that  has 
been  modified,  the  certification  problem  is  still  extremely 
difficult. 

How  can  we  improve  the  certification  situation?  The 
next  figure  gives  some  indications. 


The  size  and  context  of  the  sample  preclude  the  results 
in  the  figure  from  being  definitive  for  real-time  military 
software;  but  there  is  no  strong  reason  to  believe  that  the 
basic  trends  of  the  data  would  markedly  differ.  But,  sur¬ 
prisingly,  no  such  data  seems  to  be  available  on  real-time 
military  software.  A  USAF  program  to  capture  such  data  as 
this  on  software  development,  modification,  and  checkout, 
would  not  be  very  expensive — and  certainly  quite  valuable 
from  a  software  planning  standpoint. 
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SOFTWARE  CERTIFICATION;  POSSIBLE  IMPROVEMENTS 


One  common  way  of  certifying  aerospace  software  is  to 
simulate  it,  along  with  some  part  of  its  operating  environ¬ 
ment,  on  another  machine — generally  a  more  powerful  ground- 
based  computer.  Usually,  much  of  the  simulation  is  pro¬ 
grammed  in  machine  language,  and  thus  is  characteristically 
difficult  to  create,  modify,  and  understand.  A  language 
especially  designed  for  simulating  computer  systems  could 
markedly  improve  the  situation.  Several  promising  candi¬ 
dates  are  being  developed  or  refined,  including  SIMUPOL  [14], 
IBM's  CSS  [15],  and  ECSS,  being  developed  by  Rand  for 
NASA/ERC  [16]. 

Another  common  way  of  certifying  an  on-board  computer 
system  is  to  use  a  general-purpose  computer  to  create 
stimuli  for  the  on-board  system  and  to  evaluate  its  re¬ 
sponses.  However,  major  benefits  might  result  from  in¬ 
corporating  special-purpose  extensions  to  the  checkout  com¬ 
puter;  for  example,  parallelism  for  efficiently  checking 
independent  operations  or  carrying  along  multiple  evalua¬ 
tion  functions,  or  associative  processing  for  identifying 
when  the  contents  of  key  registers  take  on  critical  values. 

Certifying  a  computer  system  implies  being  able  to 
measure  what  it  is  doing.  Yet  many  systems  are  still  de¬ 
signed  or  implemented  simply  to  maximize  performance  or  to 
minimize  response  time,  with  little  or  no  attention  to 
facilitating  measurement.  Only  later  does  the  necessity 
for  measurement  arise,  resulting  in  costly  retrofits  and 
poorer  performance.  Certainly,  the  SAGE  experience  [17] 
indicates  the  folly  of  such  an  oversight. 

If  a  program  is  being  modified  on-line,  it  should  be 
possible  to  exercise  immediately  the  modified  program  by 
executing  it  interpretively  with  respect  to  several  sets 
of  nominal  and  critical  input  parameters .  Thus ,  the  on¬ 
line  programmer  (or  his  testing  associate)  could  perform 
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a  good  deal  of  checkout  on  a  modification  before  incor¬ 
porating  it  in  the  program.  For  a  discussion  of  other 
certification  techniques  see  Ref.  18. 

The  USAF  has  certainly  found  the  advantages  of  a 
dedicated  hardware  testing  organization  sufficient  to  justify 
considerable  expenditures  on  hardware  test  facilities.  A 
dedicated  software-testing  organization  would  offer  com¬ 
parable  advantages;  these  are  enumerated  on  the  next  page. 


•  USAF  HARDWARE  TESTING  FACILITIES 


•  USAF 


CENTRIFUGES 

VIBRATORS 

VACUUM  CHAMBERS 

ENVIRONMENT  SIMULATORS 

SOFTWARE  TESTING  FACILITIES 
NONE 
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DEDICATED  SOFTWARE  TESTING  FACILITY:  ADVANTAGES 

Among  the  advantages  of  a  dedicated  testing  facility 

are: 

Continuity .  The  testing  staff  does  not  disband  at  the 
end  of  each  project.  Being  process-oriented 
rather  than  project-oriented,  it  can  build  on 
accumulated  testing  experience  and  develop  special 
tools  to  make  testing  more  thorough  and  efficient. 

Motivation.  The  testing  staff  member  is  working  for 
the  client,  not  against  his  colleagues  who  de¬ 
veloped  the  system.  There  is  no  institutional 
bias  toward  calling  the  system  a  success. 

Muscle.  The  testing  organization  generally  has  the 
ear  of  the  client,  and  can  influence  the  system 
development  specifications  to  make  sure  that 
testing  considerations  are  appropriately  included. 

On  the  hardware  side,  the  Air  Force  realizes  these 
advantages  with  the  inertial  guidance  test  facility  at 
Holloman  AFB ,  Materials  Lab  at  Wright-Patterson  AFB,  the 
environment  simulators  at  Arnold  AFB,  the  electronics¬ 
testing  facilities  at  Hanscom  AFB,  and  many  others.  But 
how  many  dedicated,  project-independent  software- testing 
facilities  does  the  USAF  have?  None. 
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RELATIVE  IMPORTANCE  OF  SOFTWARE  TESTING 


The  data  presented  here  come  from  Rand  and  SDC  studies 
[9,19]  indicating  that  these  examples  of  command-control 
and  spaceborne  programming  projects  are  typical  of  such 
projects  in  general,  with  regard  to  the  percentage  break¬ 
down  of  software  development.  Thus,  during  the  1970s  the 
Air  Force  can  expect  to  spend  almost  half  of  its  software 
budget  for  military  space  operations  on  the  checkout  and 
test  phases  of  computet -program  implementation:  two  to 
three  times  as  much  as  it  will  pay  for  having  the  programs 
coded. 

How  much  will  this  be  in  dollars?  This  is  highly  un¬ 
certain;  but  for  a  rough  comparison,  suppose  that  the  total 
computing  bill  for  military  space  operations  during  the 
seventies  is  about  the  same  as  NASA's  computing  bill  for 
manned  space-flight  operations  during  the  sixties,  which 
Nehama  estimates  at  about  two  billion  dollars  [20],  Assum¬ 
ing,  generously,  that  hardware  and  software  costs  will  be 
about  equal,  we  arrive  at  a  budget  of  about  $500,000,000 
for  software  checkout  and  tests  associated  with  military 
space  operations  in  the  coming  decade. 

Given  a  coat  of  this  magnitude,  it  would  not  be  dif¬ 
ficult  to  justify  a  dedicated  software-testing  facility  on 
strictly  an  economic  basis.  But  this  would  be  inappropriate. 
It  must  be  justified  primarily  on  a  military  preparedness 
basis.  The  nation's  defense  can  little  afford  to  be  con¬ 
strained  by  inflexible  software.  But  even  less  can  the 
nation  afford  to  be  drawn  into  strategic  crises,  or  have 
its  defenses  weakened,  because  of  errors  in  software  options 
or  modifications. 
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SOFTWARE  CERTIFICATION;  A  FIRST  STEP 

The  software  certification  problem  confronts  the  Air 
Force  as  seriously  in  other  major  areas — strategic  and 
tactical  command  and  control,  and  air  defense — as  it  does 
in  space  operations.  Of  course,  it  is  also  a  major  concern 
in  the  operations  of  NASA,  the  U.S.  Navy,  U.S.  Army,  and 
other  agencies. 

But,  since  the  greatest  concern  with  the  problem  falls 
to  the  Air  Force,  it  is  at  once  the  opportunity  and  the 
responsibility  of  the  Air  Force  to  provide  leadership  in 
developing  improved  techniques  and  facilities  for  software 
certification. 

An  important  first  step  would  be  to  compile  a  defini¬ 
tive  study  on  software-certification  practices  in  the  Air 
Force ,  inc luding : 

1)  Existing  techniques  and  facilities  in  the  Air 
Force ; 

2)  Existing  techniques  and  facilities  in  other 
agencies ; 

3)  Promising  new  approaches  to  software  certification 

4)  Distribution  of  Air  Force  software  research  effort 
does  45  percent  to  50  percent  go  towards  testing- 
oriented  research? 

5)  Nature  and  feasibility  of  a  dedicated  Air  Force 
facility  for  software  testing. 
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CONCLUSIONS 

Most  military  space  operations  during  the  1970s 
will  not  strain  +  .e  available  information-processing  capa¬ 
bilities.  But  there  are  some  operations — real-time  image 
processing,  STS  on-board  computing,  multi-sensor  data 
analysis,  decision-oriented  displays,  and  others — for  which 
the  Air  ^orce  will  not  be  able  to  reach  "on  the  shelf"  and 
find  tools  capable  of  doing  the  job.  The  USAF  will  have  to 
settle  for  reduced  capabilities  in  these  areas  unless  space- 
mission  planners  more  thoroughly  investigate  their  detailed 
information-processing  requirements  and  couple  them  to  the 
USAF  R&D  program  in  information  processing. 

Overall  cost  of  an  on-board  computer  system  is  minimized 
by  procuring  computer  hardware  with  at  least  50  percent  to 
100  percent  more  capacity  than  is  absolutely  necessary.  The 
optimal  excess  hardware  capacity  will  increase  as  the  ratio 
of  software -to- hardware  costs  increases  during  the  seventies. 
Furthermore,  it  is  far  more  risky  to  buy  too  little  excess 
hardware  capacity  than  too  much.  However,  buying  extra 
hardware  does  not  eliminate  the  need  for  careful  software- 
configuration  control  thereafter. 

The  proposed  Space  Transportation  System  (STS)  will 
strain  the  available  information  processing  capabilities. 
Historical  data  on  similar  software  projects  indicate  that 
six  or  seven  calendar  years  are  probably  required  to  design, 
develop,  and  check  out  the  software  for  a  project  of  the 
magnitude  and  complexity  of  STS.  To  make  sure  that  soft¬ 
ware  does  not  slip  the  overall  schedule,  STS  planners  must 
begin  to  design  the  software  now.  Specifically,  the  Air 
Force  should  be  devoting  as  much  contractor  effort  to  such 
questions  as  centralized  versus  distributed  launch  checkout 
control  and  software  versus  hardware  for  signal  processing 
as  is  currently  being  devoted  to  thermal  protection  and 
propellant-tanking  alternatives.  Furthermore,  the  USAF 
should  push  R&D  on  high-capability  flight  computers  for  STS. 
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Preprogrammed  space  software  in  the  1970s  will 
allow  many  more  user  options.  Serious  consideration  is 
being  given  to  "programmer-astronauts"  and  real-time  soft¬ 
ware  modification  in  order  to  provide  non- preprogrammed 
flexibility  to  USAF  space-mission  operations.  But,  coupled 
with  our  inadequate  capabilities  to  check  out  and  certify 
software,  such  measures  could  have  disastrous  consequences 
in  escalating  strategic  crises  or  degrading  critical  de¬ 
fense  capabilities  because  of  undetected  errors  in  soft¬ 
ware  options  or  modifications.  The  USAF  could  improve  the 
situation  by  following  its  hardware-development  philosophy 
and  establishing  a  dedicated  facility  for  software  testing, 
along  with  operational  procedures  for  using  the  facility 
during  a  major  software  project's  development.  The  USAF 
should  establish  a  study  group  to  report  on  current  certifi¬ 
cation  practices  and  the  feasibility  of  such  a  dedicated 
facility. 
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